Subject: Issues in latest spec (NetBIOS etc)

From: "Steve Klein" <[email-masked]>
Date: Mon, 29 Aug 94 13:24:40 EDT

Reference: Note from: Paul Brittain dated Wed, 3 Aug 94 18:30:11 BST

Paul: my comments to the first part of your note are denoted with an SCK>.
Connect RIGleteers: Please post any other comments this week if you want
                    any influence on the consensus for this item.

NETBIOS CIRCUIT SETUP
=====================

Section 4.1.1. documents a Netbios connect flow that uses NQ/NR_ex
messages to locate a name AND (IMPLICITLY) TO EXCHANGE NETBIOS SESSION
NUMBERS.

The implied action has two consequences:

-        The NQ_ex should ALWAYS cause a NAME_QUERY to flow on the LAN
         and cannot be replied to from cache (unless it is part of a
         FIND.NAME request and has a zero session number)

SCK> I agree.  That is a mistake in my explorer frame FSM.  See my next
SCK> note with my comments to the Explorer FSM part of your note.
SCK> It is very important to propogate the NETBIOS local session numbers
SCK> from NAME_QUERYs and NAME_RECOGNIZEDs.  An implementation could
SCK> respond to a SSP NETBIOS_NQ containing a FIND.NAME type NAME_QUERY
SCK> based on cached information if it felt such a function was useful.
SCK> I think our standard should say that all SSP NETBIOS_NQs cause a
SCK> NAME_QUERY to flow on the LAN.

         (This is also the key to supporting multiple NetBIOS sesisons
          between the same MAC addresses.  If the NQ_ex always causes the
          session number to be propagated on the LAN, multiple sessions
          will work without any need for NQ_cs messages.  See Thang Do's
          note on this subject)

-        If this really is the flow we intend to use, should we
         document the NQ/NR_cs messages in the FSM as they will not
         be used?

There are two corresponding parts to the potential solutions to this
issue:

-        Either we document an 'explorer FSM' that specifically
         disallows replies to NQ_ex requests from cache (apart from
         FIND.NAME operations), or we adopt the convention that
         FIND.NAME requests correspond to _ex messages, and session
         setup attempts correspond to _cs messages.

-        Also we need to remove the references to NQ/NR_cs messages in the
         FSM, or we must change the flow in 4.1.1. to use NQ_cs instead
         of the NQ_ex.  (I am, for now, ignoring any desire to keep the NQ_cs
         messages for back-compatability as that is independent of this
         discussion)

SCK> The intent of my separation of topology info and circuit establishment
SCK> was to always use NETBIOS_NQ_ex and NETBIOS_NR_ex.  NETBIOS_NQ_cs
SCK> and NETBIOS_NR_cs were just the old messages used by RFC 1434
SCK> implementations.  I say we remove the NETBIOS_NQ_cs and NETBIOS_NR_cs
SCK> from the FSMs since they only seem to cause confusion.  Those
SCK> interested in backward compatibility will know what to do with them
SCK> if they receive them.

My preference is to preserve the flow of 4.1.1, and to document the
explorer FSM and main FSMs to remove NQ/NR_cs messages.
Obviously such messages will still be required if you want to talk
to a back-level DLSw, but leaving them in here leads to confusion
over the main FSM that defines the DLSw Standard!

SCK> This in my opinion also.  Unless there is a disagreement from anyone
SCK> else in the Connect group, this will be Connect RIGlet position.

However this does mean that all NetBIOS datagrams will be flowing as DATAFRAMEs
instead of DGRMFRAMEs until the SABME flows between the NetBIOS end nodes, so
it is not an entirely clear-cut case.  What do you all think?

SCK> Yes, NETBIOS datagrams will flow as DATAFRAMEs since there are no
SCK> Circuit IDs to use for DGRMFRAMEs.

Please post your opinions on this issue ASAP so that we can work on documenting
the FSMs as everyone would like to see them.